(Item 008485) Update DLUR name substitution processing ------------------------------------------------------ The following describes a problem encountered by a VTAM customer when using DLUR - the solution follows the ******************* divider: The problem occurs when a BIND containing network qualified PLU and SLU names is received at the DLUR and is forwarded to a dependent SLU (after the network IDs have been stripped off, if appropriate). We discovered (the hard way) that some dependent SLUs will check the PLU name in the BIND against the PLU name provided in the original LOGON request, to make sure that the BIND is, in fact, coming from the PLU from which the SLU requested the session. (The same verification can also be achieved if the SLU includes a User Request Correlator or URC on the INIT_SELF RU, which is returned by the PLU in the BIND. However, not all SLUs provide a URC on INIT_SELF.) Here is background on how this problem evolved: Problem History: To Qualify or Not To Qualify? ----------------------------------------------- VTAM thinks this all started when we ran into this problem while testing our DLUS support. A DLUR-served dependent SLU attempted to LOGON to an application using an Uninterpreted Name for the PLU. The VTAM DLUS translated the Uninterpreted Name into the real PLU name prior to searching for the PLU. In this case, the PLU was found in subarea (with the DLUS acting as the interchange node). The CDINIT RU that was sent toward the PLU included the following: - The uninterpreted name provided by the SLU on the LOGON - The real name of the primary LU (as translated by the DLUS from the uninterpreted name) - Indicator that the SLU does NOT support network qualified names in BIND The VTAM that owned the PLU built a FID4 BIND with Unqualified Names for both the PLU and SLU, with the PLU name being the Uninterpreted name provided by the SLU. An additional CV 0E (type F3) was also included on the BIND, which contained the PLU's real name (network qualified). This BIND then flowed through the subarea, across the interchange node and into the APPN network. When it arrived at the DLUR node, it was rejected due to the lack of network qualified PLU name, SLU name or both. Rather than require all DLUR implementations to change, VTAM decided it would be best to provide a VTAM fix for this problem (probably for the same reasons that the DLUR-deadlock problem was resolved in VTAM). The solution was to include network qualified names on these BINDs. However, if we network-qualified the "Uninterpreted Name", then VTAM would no longer include the CV 0E (type F3) containing the REAL PLU NAME on the BIND. (I believe that the CV 0E with the PLU name is only allowed, if the BIND contains non-network qualified names.) If the CV 0E with the REAL PLU NAME is not included on the BIND, intermediate VTAM NNs on the BIND path (who did not know about the session until the BIND arrived) would create a cross-domain resource definition for the Uninterpreted Name, thinking it was the REAL PLU NAME. This is not in keeping with the defined use of Uninterpreted Names, which are suppose to be known only in the SLU's domain. So instead of adding the NETID to the uninterpreted name, VTAM decided to NOT SEND the Uninterpreted Name to the PLU node when the SLU was DLUR-served. This way, the network-qualified REAL PLU name would be included in the BIND instead. (This is the way VTAM already does it when the PLU is located "in APPN", rather than "in subarea".) This worked well for a while, until we learned of the dependent SLU implementations that REQUIRE that the PLU name provided on the LOGON request (the Uninterpreted Name) be included in the BIND, or the BIND would be rejected. Since the intent of the DLUR architecture is to support these legacy dependent LUs without requiring them to change, we need to find a way to give these SLUs what they need (the same PLU name in BIND as was in the LOGON request) while preserving the functionality of APPN networks. The question that we think is at the root of this problem is this: Should APPN BINDs destined for DLUR-served LUs contain network qualified names or unqualified names? What If These BINDs Are Sent With Unqualified PLU/SLU Names? ------------------------------------------------------------ Our initial reaction was that these BINDs must be allowed to contain unqualified names. This is because, if VTAM/NCP decide to send network qualified PLU/SLU names, they include the network qualified REAL PLU name (instead of the Uninterpreted Name), which means the SLU does not get the same PLU name in the BIND that it sent on the LOGON request. If VTAM/NCP simply network qualified the Uninterpreted PLU Name, then the problem described above would result (that is, VTAM building a CDRSC for the Uninterpreted PLU Name). However, if unqualified names are built into the BIND (and the CV 0E with the qualified REAL PLU name is appended), then intermediate VTAMs will use the CV 0E to build a CDRSC for the REAL PLU name, rather than the uninterpreted PLU name, which is what we want to occur. So, the question then becomes: Should a DLUR be allowed to rejects BINDs with unqualified PLU and/or SLU names? When I checked the DLUR8 version of the DLUR document on the AIW Web page, I found the following under section 8.1.4 BIND Processing: DLUR8, Section 8.1.4, BIND Processing ------------------------------------- - network-qualified name processing - the NETIDs (if any) will be stripped from the LU names in the BIND if necessary, based on the network-qualified names support indicator in the CV X'0C' in the +RSP(ACTLU); This seems to imply that DLUR nodes must be prepared to received BINDs with non-network qualified names in them. However, upon further discussion with the APPN Architects, we realized that other problems can occur if BINDs are sent to DLUR nodes without network qualified names. Consider the case where this BIND must traverse one or more subnetwork (Border Node) boundaries between the PLU node and the DLUR. The EBN design includes a function called "RSCV Caching" that allows EBNs to save RSCVs that are computed during Locate flows (for cross-subnetwork sessions) so that they can be used immediately when the ensuing BIND is received (rather than having to send another APPN Locate). However, the EBN design also had to consider the case where the "cached RSCV" was purged before the BIND arrived. In this case, the EBN is still required to send another APPN search (with the "Owning CP Respond" bit set) to compute a new RSCV for use in the next APPN subnetwork. The problem results from the fact that the BIND no longer contains the network-qualified SLU name. So the EBN would have no choice but to search for the SLU with an "alias name" (that is, the "Authentic Network ID" indicator would have to indicate "not authentic".) The problem here is that the EBN is not guaranteed to find the same SLU! If two SLUs exist with the same name but different network IDs, it is possible that the EBN will find the wrong SLU during this search and forward the BIND to the wrong place! This is clearly not acceptable. So What Options Are Left? ------------------------- In order to satisfy the SLU requirement to receive the same PLU name in BIND as was provided on the LOGON request, the PLU name in the BIND would have to be the unqualified Uninterpreted Name of the PLU. But in order to avoid the EBN problem described above, the SLU name would have to be network qualified. We considered the possibility of building BINDs with an unqualified PLU name and a network qualified SLU name (and still providing the REAL PLU name in a CV 0E type F3). But we realized that MANY VTAMs/NCPs would may have to apply this type of fix (even on VTAMs that may not be in THIS CUSTOMERs network, if the DLUR SLU in question uses APPLs on those VTAMs). This may even include VTAMs and/or NCPs that are no longer in service! Based on this, VTAM and the APPN architects agreed that this approach should be avoided, if at all possible. (NOTE: It may still be the only possibility, if the LOGAPPL problem described later cannot be solved some other way. Read on...) With all of our options falling through the cracks, we decided to take a step back and look at this again. In particular, if dependent SLUs require the same name in BIND as on the LOGON request and VTAM/NCP have always included network qualified PLU/SLU names in APPN BINDs, then why didn't this break PRIOR to the introduction of DLUR/S? The answer is fairly obvious: Prior to DLUR/S, the VTAM that owned the dependent SLU (or one of it's NCPs) was always on the session path. When a BIND with network qualified names (and the REAL PLU name) was received by the owning VTAM for an SLU that did not support them, existing logic was driven to: (a) strip the network ID off the SLU name in the BIND, and (b) substitute the Uninterpreted PLU Name for the Real PLU Name that was carried in the BIND. This guaranteed that these BINDs arrive at the SLU with the correct (Uninterpreted) PLU name. (The BINDs were also UNEXTENDED, if necessary, before being sent to the SLU.) DLUR/S has now broken the assumption that the VTAM that owns the SLU will always be on the session path. And even if this VTAM WAS on the session path, this VTAM cannot be responsible for substituting the unqualified names in the BIND, because the BIND must still flow over one or more APPN connections on route to the DLUR before it reaches the SLU. If unqualified names are substituted and there is a subnet boundary between the DLUS and the DLUR, then the same EBN problem described earlier would result. So the only node that MIGHT be able to perform this name substitution at BIND time would be the DLUR node. Name Substitution By DLUR Nodes? -------------------------------- After extensive discussion, VTAM and the APPN Architects feel that this would be the ideal solution. However, this would mean that DLURs must intercept LOGON requests from their served SLUs and save the PLU name (as provided by the SLU) for later substitution into the BIND. While looking at the DLUR8 document on the AIW Web page, I noticed the following write-up on PLU name substitution in the same section on BIND routing (8.1.4): - name substitution processing - the PLU name will be replaced if necessary, based on whether or not the saved and BIND's URCs match: - if the URCs do not match, BIND processing will continue; - if the URCs match, the BIND PLU name will be replaced with the saved PLU name, and the DLUR will discard the saved URC and the saved PLU name; So, it appears as though DLUR nodes already do PLU name substitution in some cases (when the SLU provides a URC on the LOGON request). But what about cases where the SLU does NOT provide a URC on the LOGON request? Also (for those who recall the discussions we had at AIW 14 on the DLUR deadlock problem), not all LOGON requests from dependent SLUs are INIT_SELF RUs. Some are "unformatted LOGONs" (or USS LOGONs). It is not clear whether DLUR nodes would be able to parse an unformatted LOGON request and extract the PLU name. Even with these potential problems, VTAM and the APPN architects felt that this was best solution to propose to the AIW. For USS (unformatted) LOGONs, if the DLUR node cannot not extract the PLU name from the unformatted LOGON, then the SLU probably does not know where in this LOGON request the PLU name is either. So, it would seem that the SLU would not be able to "verify" the PLU name later when the BIND arrives. (We all agreed that this was acceptable, at least until we discover a REAL field problem with unformatted LOGONs.) To resolve the URC problem, it was suggested that DLUR nodes could generate a URC (if one was not provided by the SLU on the INITSELF RU) and insert it into the INITSELF RU before forwarding it to the DLUS. The DLUR must also REMEMBER that the URC was generated by the DLUR and strip it off the BIND before forwarding the BIND to the SLU. If this logic is implemented at the DLUR, then the same "PLU Name Substitution" logic described above would kick in when the BIND arrives, so the SLU would receive the PLU name it needs. URC NOTE: The customer reporting this problem informed us that their dependent SLU implementation builds a format 0 INIT_SELF, rather than format 1. Format 0 INIT_SELF does not contain a field for the URC. However, this could be solved by having the DLUR add a CV 0A (URC) to the INIT_SELF (format 0) before forwarding it to the DLUS. Although "technically" the INIT_SELF format 0 does not allow CVs, we could make an exception for the DLUR/S case...it would not be the first time. However, this solution means that a co-requisite VTAM APAR may have to be applied at the same time as the DLUR fix. The APPN Architects and I were poised to propose the above solution to the AIW, when another wrinkle came up. VTAM provides a function by which the SSCP(SLU) can initiate a session on behalf of the SLU, that is, the LOGAPPL (or Autologon) function. If a dependent SLU has a LOGAPPL on it's definition, then the owing VTAM initiates a session with the SLU and it's "controlling APPL" whenever the SLU is enabled and does not already have a session with this APPL. VTAM initiates this session by building an INIT_SELF RU on behalf of the SLU and sending it to itself. Since this INIT_SELF never flows through the DLUR, the DLUR cannot save the PLU name and substitute it later on the BIND. After thinking about this for a while, we felt this would not be a problem either. This is because if the SLU never saw the INIT_SELF RU (instead, the BIND that arrives is a "BLIND BIND" from the SLU's perspective), then how could it possibly "validity check" the PLU name in the BIND? It would not know what PLU name was in INIT_SELF! Well, the customer reporting this problem told us that the dependent SLU in question is an emulator that is "programmable". They have a "server application" running on this box that validity checks all received BINDs to make sure the correct PLU name is included. How does this box know what PLU name SHOULD be in the BIND? They do it with coordinated system definition. That is, they define the same PLU name at the SLU node that they define on the LOGAPPL operand of the SLU definition in VTAM. To avoid having to change every SLU node each time they change the name of the PLU APPL, they code a USERVAR name on the LOGAPPL statement and on these SLU boxes. If they want to change PLU APPLs, they MODIFY the USERVAR to point to the new PLU name. As long as the USERVAR name shows up in the BIND, the SLU node is happy. Unfortunately, the DLUR Name Substitution idea will not allow this to occur for LOGAPPL sessions. Conclusions (Finally!) ---------------------- If the LOGAPPL scenario (described above) was not a problem, then both VTAM and the APPN Architects feel that the DLUR Name Substitution proposal is the best (and easiest) solution to develop and roll out. This solution satisfies all of the immediate requirements (except the LOGAPPL problem). It also continues to allow all (or most) APPN BINDs to flow with network qualified names (at least as far as the DLUR node). The most appealing part of this solution is that it does not pose the same "roll-out" problems that would result if the VTAM/NCP fix (described above) were implemented. (And if customers are running with "no longer supported" versions of VTAM and NCP, then this solution may not even be possible.) Instead, this proposal affects ONLY DLUR nodes and the "fix" need only be applied to DLUR nodes that attach SLUs which (a) perform "PLU name verification" and (b) do not provide a URC on their INITSELF RUs. (Keep in mind that, if the VTAM/NCP solution is decided upon despite the roll-out problems, DLUR implementations may still require changes if they currently reject BINDs with unqualified names.) With a fairly complete understanding of the problem (we hope) and with what we feel are the two most promising proposals on the table, we would now like to open this up for discussion. Other Things To Think About! ---------------------------- The following describe other topics which came up during these discussions that may be of interest to AIW members: 1. If a DLUR implementation is running into this problem right now and they are only serving "local" (as opposed to "down-stream") dependent LUs, there is a quick circumvention for this problem. Simply include a URC on INITSELF (fmt 1) RUs. This way, the DLUR node will automatically substitute the correct PLU name into the BIND before it arrives at the SLU. This will solve all but the LOGAPPL problem, which is not a problem unless the "PLU name" definition is coordinated between VTAM and this DLUR node. 2. Because the DLUR8 document implies that DLUR nodes must support receiving BINDs with unqualified names, any DLUR node that fails a BIND for this reason could be considered in violation of the DLUR architecture. However, the DLUR Name Substitution proposal (if adopted) allows these BINDs to continue to flow with network qualified names. So we are not aware of any cases where a BIND would arrive at a DLUR node with unqualified names. We have decided to leave it up to each DLUR implementation to investigate whether their DLUR implementation has this problem and to weigh the cost of implementing a solution to this problem against the likelihood that it will actually happen in the field. However, understand that if it ever DOES happen in the field, the DLUR node will be considered in violation of the architecture. 3. If DLUR nodes do support receiving unqualified names within BINDs (and if they actually receive a BIND with unqualified names), then consideration may have to be given to whether these BINDs can be routed correctly. Two potential problems might be: (a) if the DLUR node is not able to locate the SLU representation without the SLU's network ID included on the BIND, or (b) if the DLUR node is currently serving more than one SLU with the same name but different NETIDs. It is possible that the URC on the BIND would provide enough information for the DLUR to be able to route the BIND correctly (assuming there is a URC on the BIND). If there is no URC on the BIND, then the DLUR node must find a way to ensure that the BIND is routed correctly. For the "multiple SLUs with the same name" case, if DLURs cannot find a way to ensure that the BIND is routed to the correct SLU, then the DLUR architecture may have to be updated to NOT allow a given DLUR to support multiple SLUs with the same name. (No position will be taken on this right now, as we are not sure how often, if ever, a customer will want the same DLUR to serve multiple SLUs with the same name, or even if any of the existing DLUR implementations actually support this.) Johnathan L. Harter IBM CS/390 Development YODA at IBMUSM27 Dept L16/Bldg 501, RTP, NC USIB3WDL at IBMMAIL "Do or do not...there is no try."--YODA yoda@us.ibm.com ***************************************************************** The DLUR architecture reference will be updated as follows in the "LU-LU Session Routing" chapter: 1) INIT-SELF section -------------------- The DLUR architecture currently reads: When the DLUR node receives an INIT-SELF from a DLUR-attached dependent LU, it will save the PLU name and the User Request Correlation (URC) field from the RU and associate this information with the LU. This will be changed to: When the DLUR node receives an INIT-SELF from a DLUR-attached dependent LU, - if the INIT-SELF format is Format 0, the DLUR will create a User Request Correlation (URC) (X'0A') control vector, include the control vector in the RU, and remember that the URC is DLUR-generated; - if the INIT-SELF format is Format 1, - if the URC field is not present, the DLUR will create a URC, include it in the RU, and remember that the URC is DLUR-generated. For all INIT-SELF RUs received from a DLUR-attached dependent LU the DLUR will save the PLU name and the User Request Correlation (URC) field from the RU and associate this information with the LU. 2) BIND section --------------- The DLUR architecture currently reads: * name substitution processing - the PLU name will be replaced if necessary, based on whether or not the saved and BIND's URCs match: - if the URCs do not match, BIND processing will continue; - if the URCs match, the BIND PLU name will be replaced with the saved PLU name, and the DLUR will discard the saved URC and the saved PLU name; This will be changed to: * name substitution processing - the PLU name will be replaced if necessary, based on whether or not the saved and BIND's URCs match: - if the URCs do not match, BIND processing will continue; - if the URCs match, - the BIND PLU name will be replaced with the saved PLU name, - the DLUR will discard the saved URC and the saved PLU name, and - if the URC was DLUR-generated, the URC will be removed from the BIND;